Token 经济学：Agent 时代按 Token 付费有消费者买账吗？

来源：htmlDecode("Rog3r")

原文链接：https://mp.weixin.qq.com/s/_g-HZ1Flk4Ne0rrn_MeQew

大家好，我是 Rog3r，最近在用 OpenClaw 的时候接入的都是 OpenRouter 上的免费模型，用的时候不会有 token 的价格负担，所以重度使用了几周。
不同主机上养了不同的龙虾，今天我看了一下看板上的使用量，三只龙虾，一共消耗掉了 ** 十几亿 ** 的 token，换算成主流大模型 MiniMax、GLM 和 Kimi 的费用平均下来至少是大几千了，如果是用的最顶级的 Claude Opus 4.6 成本肯定已经上万了。
更长的系统提示词、多轮工具调用、以及更复杂的 skill 加载，一起造成了当前 agent token 消耗量的无止境膨胀。对我个人来说，如果不是 Coding Plan，我是不敢直接接入 API 来使用 Agent 的。
今天小米 MiMo 团队负责人罗福莉发文提到：全球算力跟不上 Agent 时代的 Token 消耗，出路不是更便宜的 Token，而是更省 Token 的框架和更高效的模型共同进化。
SGLang 核心开发 Chayenne Zhao 把 Claude Code 接到她自己跑的推理引擎上，测了一整天  ** prefix cache 命中率 ** ，也表示数字非常难看，整个系统浪费了很多 token。
上周我用我的小龙虾在跑一个重复性很高的工作流——每次新对话，OpenClaw 都要花好几轮来搞清楚我的项目结构、工具调用的偏好、输出格式的要求。这些信息上次已经确认过了，这次又确认一遍，下次还要再来一遍。我盯着屏幕看了一会儿，大概估算了一下：这几轮"热身"消耗的 token，可能占整个 session 的三分之一，纯粹的浪费。

Prefix Cache 是怎么工作的

LLM 做推理分两步：prefill 处理输入，decode 一个 token 一个 token 往外生成。prefill 阶段，模型会对每个 token 计算一组中间状态，叫  ** KV cache ** 。同一段 prompt 前缀如果出现在两个请求里，推理引擎可以直接复用已算好的 KV cache，不用重新算一遍。
这个优化在长 session 里价值巨大。system prompt 加工具定义加项目上下文，可能有好几万 token，这些在一个 session 里基本不变。如果每次请求都能命中缓存，实际需要计算的只有最新的那几条消息。 ** 命中率 90% 和命中率 10% 之间，GPU 计算量差了将近 10 倍。 **
但 agent 框架通常是这样工作的：每一次工具调用是一个独立的 API 请求，带着完整的上下文窗口。一个用户查询可能触发好几轮工具调用，每次都带  ** 100K+ token **  的全量 context 发过去。引擎收到的是一组全新的 prefix，缓存基本全 miss。

比 Cache Miss 更基础的问题

我自己感受到的问题，比这个更基础一层。
每次新对话，我都要把同样的上下文从头建立一遍。这个项目用什么技术栈、偏好什么输出格式、遇到这类错误怎么处理——这些"工作记忆"既没有被 agent 框架沉淀成可复用的  ** SOP ** ，也没有任何机制告诉推理引擎"这段上下文在接下来几个请求里都会用到，请保持 KV cache warm"。
有一类工作更极端：纯粹的脚本操作，读文件、改内容、写回去，完全不需要模型的推理能力。但 agent 会老实地把文件内容送进上下文，等模型读完、理解、修改、返回，整个链路走一遍。这里消耗的 token，跟用一个简单脚本直接操作文件相比，可能差了 ** 几十倍 ** 。根本用错了工具。

没有人能对总效率负责

系统里有三个角色，激励结构决定了这个问题没人会去解决。
** 卖 token 的 ** ：按量计费，消耗越多收入越多。一个 session 用 700K token 还是 70K token，收入差 10 倍。
** 做推理引擎的 ** ：关心效率，prefix cache 命中率越高，GPU 利用率越高，单位成本越低。但他们没有权限改 agent 框架的请求模式，只能等请求进来尽量优化。
** 用户 ** ：订阅制下完全感知不到 token 成本。70K 还是 700K，月底扣同一笔钱，没有任何动机主动优化。
三方，三种激励，互相不交叠。 ** 没有人能对总效率负责。 **
harness 和 inference engine 之间，没有任何协议让框架告诉引擎"接下来五个请求复用同一段上下文"，也没有任何协议让引擎告诉框架"你每次重发这段前缀，合并请求能快三倍"。两边各自优化，中间的浪费无人认领。

Token 膨胀的结局

1969 年，64KB 内存把阿波罗送上了月球。2026 年，我打开一个网页，500MB 内存消耗都不算什么。每一代硬件工程师把内存做得更大，每一代软件工程师把它填满。这个循环已经持续了五十年。
后果：用户多掏 200 块买条内存条，勉强可以接受。
浪费的规模比直觉感受的更极端。有研究者统计过 LLM 推理的  ** input/output 比例：97:3 ** 。system prompt、工具调用返回、多轮对话上下文不断膨胀，真正输出的内容只占 3%。token 总量越来越大， 衡量的是 tokenizer 输入输出的字符数 ，不是实际产出的算力价值。
token 浪费的后果完全不同。 ** GPU 供给弹性远低于 DRAM ** ——HBM 被三家厂商垄断，CoWoS 先进封装产能有限，电力基础设施是硬约束。内存可以在几个月内扩产，GPU 算力的爬坡周期以年计。
这也不同于普通的云计算资源浪费。云计算里用户增加 10 倍，CPU、内存、存储的需求大致线性增长，而且这些资源通用、可互换，开发者随时可以重构代码来控制消耗。Token bloat 的结构性问题更深： ** 供应链约束高度集中，框架设计缺陷直接击败推理层优化 ** ，prefill 阶段的浪费是架构级别的，不是调参能修复的。这一轮，早期的工程纪律比以往任何一次资源浪费周期都更重要。
一个 700K token 的 session 用 70K 就能干完，意味着同样的算力可以多服务  ** 10 倍 ** 的用户，或者同一个用户可以跑 10 倍深度的任务。

出路在框架设计层

Anthropic 砍掉第三方 harness 的订阅权限，罗福莉的判断是" ** 痛苦会转化为工程纪律 ** "。我基本认同——当 token 成本变得可见，当用多少付多少取代订阅制的幻觉，框架开发者才有真实的动机去优化 context 管理。
但更根本的改变，要发生在框架设计层。调用 API 要更少。先判断这件事值不值得动用 LLM：纯脚本能解决的，直接跑脚本；可以提前固化的 SOP，沉淀成确定性流程；需要跨 session 复用的上下文，显式管理而不是每次从头重建。
agent 框架层有很大的空间来做这些事，而这些事目前几乎没人做。
token 成本确实在下降。但 agent 的普及带来的需求增长，历史上软件对硬件的关系只有一个答案： ** 需求永远比供给跑得快 ** 。商业平衡点什么时候出现，我不知道。但它出现的方式，大概率是效率先到位，成本跟着降，而不是反过来。
反过来说， ** efficiency-first 的框架和团队，现在可能是被系统性低估的 ** 。谁能率先实现同等效果下 token 消耗降低一个数量级，就能在相同硬件上服务更多用户、跑更深的 agent 任务——这不只是工程美德，是真实的护城河。
谁先建立起"token 应当被高效使用"的工程纪律，谁就能在同等算力约束下走得更远。
如果这篇文章对你有帮助，欢迎关注、点赞、转发和留言。